Introduction

It's been a versatile week with a lot of stuff going on. Let's see what we got.

Delayed Signals in Timing Checks

To begin with, the PR to handle delayed signals in timing checks as assignments has been merged at the start of the week (PR #966).

This is great because it means if timing checks like $setuphold or $recrem are used in standard cells, the delayed signals are now correctly connected. This is important for SKY130, because until now the outputs of flip-flops and latches were just left unconnected in timing simulations.

In the future, the signals should actually be delayed, but this is a task for when the timing checks get actually implemented.

Specify blocks in SKY130

To be able to perform timing simulations, the standard cells of the PDK must contain specify blocks. The open_pdk build of SKY130 did not contain these, although the source repositories of the standard libraries contained them.

After a bit of work, I figured out what was needed to add them (there was already some previous work) and opened a PR at open_pdks (#386) which has since been merged into the codebase.

Where do we stand now? With this addition, it is now possible to create a design with OpenROAD/OpenLane for SKY130 and run timing simulations with Icarus Verilog, annotating the IOPATHs.

As you can see, it takes a while for changes in the input signal to propagate to the output signal.

At the moment this does not work without changing the SDF file manually. The issue is that the specify blocks are added to the base cells and not to the drive-strength specific cells.

Briefly explained: The Verilog models for the standard cells in the SKY130 PDK are built with a hierarchical approach in mind to reduce code duplication. For each cell, a base cell is instantiated (e.g. sky130_fd_sc_hd__dfrtp) that implements the logic and timing behind the cell. This is were the specify block is added. This base cell is not used in the design, but instead the drive-strength specific cells are used (e.g. sky130_fd_sc_hd__dfrtp_1). This approach of hierarchy is not common in other PDKs. Therefore, OpenROAD expects the drive-strength specific cells to contain the specify blocks. This is why the SDF file tries to annotate them.

For this reason, we still have to manually edit the SDF file generated by OpenROAD, but I have good news for you!

Efabless Maintained SKY130 Repositories

Since Google released the open source SKY130 PDK in 2020, not much has changed in the source repositories and patch after patch started to accumulate in open_pdks.

For this reason, Efabless finally decided to fork the standard cell libraries. Now all the issues and patches can be resolved directly in the repositories, simplifying maintenance.

But this is not all!

Tim Edwards took the opportunity and reorganized the standard cell libraries: No more base cells, the drive-strength specific cells now contain the specify blocks!

With this change, it will be possible to perform timing simulations without making any changes to the standard cell libraries or the SDF file generated by OpenROAD.

SDF INTERCONNECT Implementation

This week I started with the SDF INTERCONNECT implementation. I have already opened a PR to track my changes: #973.

Right now I have implemented what is necessary at the VPI side: adding the vpiInterModPath type and implementing the get_handle_multi() function.

This makes it possible to grab a handle to a vpiInterModPath by passing two port handles, and finally annotate delays using vpi_put_delay().

On the VVP side, I was also busy:

Through the port handles I can access both vvp_net_t nodes. I have also created the functor vvp_fun_intermodpath which will get inserted into the net to provide the delay.

I can access both vvp_net_t nodes via the port handles. I also created the functor vvp_fun_intermodpath which is inserted into the net to create the delay.

But this is still very WIP, as I need to improve the detection that both ports are connected to the same net and the insertion into the netlist.

Summary

There was a lot to cover this week. I hope to write more about the SDF INTERCONNECT feature next week.

See you then!